IBIS Macromodel Task Group Meeting date: 13 February 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Michael: Develop a new clarification BIRD to more clearly define relationships between concepts, terms, and parameters such as block, block size, wave_size, etc. - Done. Michael sent draft1 to the ATM list just prior to the meeting. Michael: Send draft3 of BIRD229.1 to the ATM list. - Done. Michael sent draft3 to the ATM list on February 6, 2024. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 6th meeting. Michael moved to approve the minutes. Dian seconded the motion. There were no objections. -------------- New Discussion: BIRD229.1 draft3: Michael shared BIRD229.1 draft3 and reviewed the changes it contains, including: - Minor editorial and formatting changes - Corrected several instances of a case related typo in a value of the Type subparameter: Time_Domain -> Time_domain - AMI_output_parameters_file was changed from optional to required, per the discussion at the February 6th meeting. Michael reiterated the reason for the change. This BIRD is being relied upon to provide the information that allows the parser to address BUG227. The root name checking requested in BUG227 would not be possible if AMI_output_parameters_file were not provided. Michael noted a new explicit statement in the AMI_output_parameters_file description: "in the absence of Out or InOut parameters, the file contents would consist only of the root name" Ambrish asked for confirmation that this statement is consistent with IBIS 7.2. Michael confirmed that it is. He noted that if an AMI executable model has no Out or InOut parameters to return, then it is still obligated to return the root name in parenthesis as the contents of AMI_parameters_out. Arpad said that this draft looked good in terms of describing Michael's original plan for providing this information. However, he said he had two remaining questions: how to the handle the precision of the results comparisons, and what about Walter's proposal to put this information in the .ami file instead of the .ibs file? Arpad recalled that Michael had asked how Walter's proposal would replace the loss of the Executable_index and Direction subparameters. Michael had said he could envision ways in which the information provided by Executable_index could be added to the .ami file, but we would have to provide more information in the .ami file and might need to have a different .ami file for each of the different builds of the same .dll/.so. Arpad said he had thought about this issue, and he didn't think we would need multiple .ami files. He said we might use a Reserved parameter of type Table or List to refer to multiple sets of test data. Michael said that unless anyone sees a way in which we would be limiting ourselves with the existing proposal, he would prefer to keep the existing proposal and place the information in the .ibs file. He acknowledged that this BIRD is strictly focused on comparing the results of AMI processing, but he said this is because we have intentionally sidestepped issues like channel definition and channel measurement comparisons. We will eventually have to enhance the [Test Load] and [Test Data] keywords to properly support the AMI context, and these keywords exist in the .ibs file. Ambrish said that he preferred Michael's approach and thought we should put this information in the .ibs file. He said this BIRD is really testing the [Model], and he thought it made sense to have the test configuration and results information at the [Model] level instead of inside the .ami file. Arpad said he had raised the question only to make sure that we reviewed the options. He wanted to make sure we were not sticking with the existing proposal only for the sake of expediency. Arpad asked about the precision of the results comparisons. He said that if the goal of providing multiple sets of results is to capture minor numerical differences between OSs and architectures, the ASCII format results files will not be sufficient. He asked whether Michael was considering a binary format for the results files. Michael said that allowing a binary format file would not cause as many issues for him as putting the data in the .ami file would have. However, he noted that he was expecting the results comparisons to be informative, and he was not proposing red-flag type failures over a difference in the 15th decimal place. He said that it was really up to the user configuring the EDA tool to decide how many decimal places were considered when comparing to the golden results. He said that this BIRD is concerned first and foremost with detecting first-order errors, for example, a model not properly parsing a parameters string sent to it by a particular tool. Michael said that even if the ASCII format results files limit the ability to detect minor numerical differences, the Executable_index still has value. It documents the OS and architecture variants for which the model maker has provided formal test results. He said that ideally the model maker should provide an Executable_index entry for each line provided in their [Algorithmic Model] keyword, and he would like to encourage that behavior. Michael said that the goal of this BIRD is to allow model makers and tool vendors to find issues with their own and each other's work as early as possible. Michael moved to submit this version (draft3) to the Open Forum as BIRD229.1. Lance seconded. There were no objections. Block, "block size", wave_size clarification BIRD: Michael said he had reviewed the language used in IBIS 7.2. He said the goal of this proposal would be to address any possible confusion for readers who might have gotten the impression that "block_size" (which is never actually used in the text) is some alternate to wave_size. Michael reviewed the draft1 he had sent out. He said that the only five places in IBIS 7.2 that talk about a "block" in ambiguous terms are in the BCI parameters sections. He said there is repeated text appearing in the reference flows in three places that first introduces the use of block: "Once all blocks of the input waveform have been processed..." He reviewed new language he had added defining a block as: "... group of sequential waveform samples" Arpad noted that Michael had added a qualifier: "(note that a block is assumed to contain waveform samples for at least one complete symbol)." Arpad asked whether this was a new technical change. Michael said he had added the statement, but he was open to removing it. Arpad said this seemed to him like a reasonable statement, but he wasn't sure if there would ever be a case where this restriction didn't make sense. In the BCI messaging parameters, Michael reviewed new text he had added: "Note that a block is assumed to contain waveform samples for at least one completed UI or symbol." Arpad said that "UI or symbol" was misleading, as it implied they might be two different things. The group arrived at "UI (symbol time)". Michael noted one additional minor issue in IBIS 7.2. He said the text does not explicitly state a minimum allowed value for BCI_Training_UI or BCI_Message_Interval_UI. Therefore, it is not stated that the value 0 is invalid. Michael noted two locations where he had aligned the language with our convention that "shall" is used for things that must be true and for which the parser is able to check. For example: "BCI_Message_Interval_UI shall be present if BCI_Protocol is present." Arpad thanked Michael for starting the discussion and creating the first draft. Arpad asked everyone to review the draft and think about possible language clarifications. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: - None. ------------- Next meeting: 20 February 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives